Modeling Activities in C++

classes for the support of activities in C++ [Stroustrup 91]. The distinction between two important types of implementations of activities: initiating activities and reacting activities. Paper organization. In section 2 we discuss the use of activities as they apply to the modeling process. We use card games as a concrete example, and we discuss generally the fundamental characteristics of activities. In section 3 we present an implementation of activities in C++. A general activity class may be used for describing application speci c activity classes. The general activity class forms the basis for a framework. In section 3.1 the framework supports initiating activities: the activity has the initiative and will activate { and control { the participants whenever their participation is needed. In section 3.2 the framework supports reacting activities: the participants have the initiative and the activity will only react upon { and control { their requests. In section 4 we review an experimental project that focused on the construction of a framework for card games based on the notion of activities, and summarize the experience from the project. In section 5 we summarize the proposals and the results of the paper. 2 Modeling with Activities We shall use a card game as a concrete example to illustrate the use of activities in the modeling process. Through this example, we hope to demonstrate and discuss the fundamental characteristics of activities. Card Game Example Our intuitive understanding of a card game is that it is a human activity { it involves a speci c kind of interaction between people that exists over a duration of time. More importantly, like other activities we engage in, a card game comprises recurring patterns of interaction (part-activities) 1 that form its totality. As such, the card game is an intuitive example that allows us to identify a commonly understood 1We distinguish between part-activities and sub-activities: Descendant activities { activities specialized from another activity { are called sub-activities or just activities. Activities aggregated to form larger activities are called part-activities. activity, and explicitly abstract and model its aspects. Figure 2 illustrates the structure for a game, consisting of an activity theGame and the participating objects player1-player4. player4 player2 player1 theGame player3 Figure 2: The Card Game Example The particular example that serves as our model is the card game of Five Hundred. The object of the game is to score 500 points before the other players. Each game comprises one or more rounds; players are dealt cards and play against one another in each round. A player wins (or loses) points at the end of each round depending on how well he/she plays. At the highest level of organisation, we can create a cardGame activity that represents the totality of interaction in the game. This activity actually comprises several subordinate phases: a gameOpening phase (where initialisation and set-up take place), a gameRounds phase (in which one or more rounds are played), and a gameClosing phase (where cleanup procedures take place). We consider the activity cardGame to be composed of the part-activities gameOpening, gameRounds and gameClosing executed in sequence. As most of the signi cant interaction takes place during each round, we shall further decompose the gameRounds part-activity. This phase of the game comprises one or more rounds { each of which is a part-activity. Like the cardGame, a gameRounds partactivity comprises an opening phase (roundOpening), a central execution phase (roundPlay) and a closing phase (roundClosing). In our normal understanding, the gameRound partactivity is where most of the card playing takes place. Each round has three distinct stages: 1. dealing: Cards are dealt in a special sequence to each player. 2. bidding: Each player is successively asked to make a bid { the players bid against each other, until the highest bidder is found. The player with the winning bid starts the game. 3 3. trickTaking: After bidding, the players engage in taking tricks. A trick involves each player putting down a card; the player whose card beats the others is said to have taken the trick. For 4 players, the trick-taking phase of each round involves the playing of 10 tricks. Each activity/part-activity is responsible for managing its associated interaction. For instance, the Bidding part-activity has to control the sequence of bid actions performed by the players { as each player makes a bid, the part-activity will ensure that certain constraints are in force: is the present bid legal? Who is the next bidder? When is the bidding process over and who is the winner? cardGame gameRounds gameOpening bidding dealing trickTaking roundOpening gameClosing roundClosing roundPlay Figure 3: Card Game Activities and Part-Activities Figure 3 illustrates the hierarchical organisation of the activity of a Five Hundred game: cardGame invokes gameRound which, in turn, invokes roundPlay, etc. Fundamentals of Activities. Activities are abstractions over interactions between components, as exempli ed by the card game example. Such activities are identi ed and then classi ed as cardGames. We have seen that an activity may be composed of part-activities: cardGame is seen as an aggregation of gameOpening, etc. The game of Five Hundred is only one example of a card game; another example is the Blackjack (21) card game. Therefore, activities may be specialized: for example, cardGame may be specialized into fiveHundred or blackjack game activities. A general description of abstraction for activities in the form of classi cation, specialization and aggregation is given in [Kristensen 93b]. In the card game example the players are the components; they participate in the game. For simplicity, we assume that the number of players is xed and there is no exchange of players. In the card game the players take turn, for example, either bidding, playing a card, etc., { always according to the rules of the speci c card game. This sequence of actions forms the card game activity. The legal sequence (and control) of possible actions taken by the participating players is an abstraction over the possible games to be played in this speci c type of card game. The term transverse structure denotes the totality of the activity phenomenon and the participating phenomena. A transverse structure is performing. The term transverse activity denotes the abstraction of the actual sequence of actions (the abstraction of these in terms of the activity phenomenon) taken by the participants. The activity is in progress. The directive is the action description part of the transverse activity. In Figure 4 we illustrate the fundamental elements of activities: The transverse structure consists of a transverse activity (with a directive) and a number of participants. activity directive participant participant participant participant Figure 4: Transverse Structure The participants may be seen as active, { either explicitly as active objects { or more likely in this example implicitly by means of some interface to the \active" users, who will invoke the methods of the participants. The point is that the participants have the initiative towards the transverse activity by calling methods of the activity (these calls may provide feedback to the participants (and the users) to direct what kind of \input" is needed afterwards). The transverse activity is guiding the actions taken by the participants and may in some cases prohibit an action from being executed. Alternatively the participants may be seen as passive objects, controlled and activated by the transverse activity. In this situation, the activity will have the initiative towards the participants by call4 ing methods of the participants in order to make the participants contribute to the progress of the activity. A participant will then possibly call a method of the activity { either acting on its own internal logic, or by prompting the user for directions on what to do. In this case, the activity continuously guides the participants and also controls the actions taken by the participants with respect to the activity's method calls. 3 Implementation In C++ an activity is modeled by an object. The directive of an activity is implemented by a method. The associated participants are denoted by references between the activity object and each participant, and visa versa. An activity object has a state. The state is composed of some data and a point of execution, both of which can be simple or complex. The state registers the current situation of the activity. Whenever an action is performed by a participant in the activity { either on its own initiative or requested by the activity object itself { the activity object checks its state to control the legality of the action and { if the action is approved { updates its state according to the e ect of the action. Activities can be initiating or reacting, re ecting di erent approaches to a system's overall design. Initiating activities may be used where there is a central thread of execution dominating the system. Here, the activity will usually drive program execution, activating the participants as needed (e.g. programs in single-tasking environments such as DOS). Alternatively, reacting activities will passively await activation, to be carried out by the participants. These participants may be executing concurrently or be controlled by another portion of the system that is acting as the main program. Such activities may be employed in multitasking environments and event-driven systems. General Activity Class. Activities and participants are described as subclasses of general classes, activity and participant respectively. The class activity is described as follows: class Activity { public: Activity( Activity* p = NULL ); virtual void activate() = 0; boolean inProgress() const { return ( h_begun && ! i_complete ); } boolean hasBegun() const { return h_begun; } boolean isComplete() const { return i_complete; } virtual ~Activity(); protected: virtual void beginActivity() { h_begun = TRUE; } virtual void endActivity() { i_complete = TRUE; } boolean h_begun, i_complete; Activity* parent; }; Activity::Activity( Activity* p = NULL ) { parent = p; h_begun = i_complete = FALSE; }The methods beginActivity and endActivity are used for setting the state of the activity, while the methods inProgress, hasBegun and isComplete are used for measuring the overall state of the activity. The directive of the activity is modeled by the abstract method activate, with di erent implementations for initiating and reacting activities. The general form that speci c activate methods should take is: void activate() { // mark activity as begun, // perform actions, and // mark activity as complete } Subclasses of activity may have methods that accept message requests from participants. Any methods that are added in a speci c subclass of activity must conform to the following skeleton: void method_Accept() { // if activity in progress // then perform actions } A method of any activity class can only be invoked if the activity is still performing { otherwise, the invocation will be agged as an error. The class participant is described as follows: 5 class Participant { public: Participant( Activity* a = NULL ); void setOwner( Activity* a ) { owner = a; } virtual ~Participant(); protected: Activity* owner; }; Concrete subclasses of participant will have methods that call the accept-methods of an activity. These are termed as request-methods, as they query an activity to ask it to perform a special action. The general form for request-methods is: void method_Request( SomeActivity& a ) { a.method_Accept(); } activate some Participant object some Activity object method_Request method_Accept Figure 5: General Activity & Participant Object In Figure 5, we illustrate a general activity object with the method method Request, and a general participant object with the methods method Accept and activate. General Schematic Example. The activity object theActivity is described by SomeActivity, a subclass of Activity. In the method activate, we describe (as an example) the sequential execution of two partactivities pa1 and pa2. Note how theActivity is composed of the two part-activities. class SomeActivity : public Activity { public: SomeActivity( Activity* a ); virtual void activate(); void F_Accept(); virtual ~SomeActivity(); private: PartActivity1* pa1; PartActivity2* pa2; }; void SomeActivity::activate() { // mark activity as begun, // activate PartActivity pa1, // activate PartActivity pa2, and // mark activity as complete }void SomeActivity::F_Accept() { // if activity in progress // then perform actions } SomeActivity theActivity; The method activate models the lifecycle of theActivity. F Accept models an operation available for theActivity to be invoked by a participant. An operation such as F Accept will only execute if activate is under execution, i.e. the activity is inProgress. In the activity classes PartActivity1 and PartActivity2, we describe various operations available for the activities, here exempli ed by F1 Accept and F2 Accept. We also describe the activate method: class PartActivity1 : public Activity { public: PartActivity1( Activity* a); virtual void activate() { // mark activity as begun, // call to a participant: aParticipant.F1_Request( this ); // and mark activity as complete }void F1_Accept() { // if activity in progress // then perform actions }virtual ~PartActivity1(); }; class PartActivity2 : public Activity { public: PartActivity2( Activity* a); virtual void activate() { ... } void F2_Accept() { ... } virtual ~PartActivity2(); }; 6 activate activate activate F1_Request F2_Request pa1 pa2 aParticipant theActivity F_Accept F1_Accept F2_Accept Figure 6: General Activity Example In Figure 6, we illustrate a general activity theActivity, a participant aParticipant, and partactivities pa1 and pa2. The participant object aParticipant is described by SomeParticipant, which is a subclass of Participant. In SomeParticipant, we describe request-methods (F1 Request and F2 Request) which will be used to ask aParticipant to contribute to the execution of pa1 and pa2. This is achieved by calling pa1's accept-methods { F1 Accept and F2 Accept, which receive aParticipant's requests to contribute. class SomeParticipant : public Participant { public: SomeParticipant( Activity* a ); void F1_Request( PartActivity1& p ) { p.F1_Accept(); // call to an activity }void F2_Request( PartActivity2& p ) { p.F2_Accept(); // call to an activity } }; SomeParticipant aParticipant; void main() { // ... theActivity.activate(); }Example: Card Game. The following simpli ed version of the card game example illustrates the use of the general classes Activity and Participant { a single round of a Five Hundred game will be modeled. An activity object theRound, comprises three part-activities: theDealing, theBidding and theTricks. Each of these part-activities respectively model the dealing, bidding and trick-taking phases of a round. The theRound activity is the parent of these three part-activities. class RoundActivity : public Activity { public: RoundActivity( Activity* a = NULL ); virtual void activate(); // ... private: DealingActivity* theDealing; BiddingActivity* theBidding; TrickTakingActivity* theTricks; }; RoundActivity::RoundActivity ( Activity* a = NULL ) : Activity(a) { theDealing = new DealingActivity( this ); theBidding = new BiddingActivity( this ); theTricks = new TrickTakingActivity( this ); } RoundActivity theRound; The four players (thePlayers[4]) are the participants in theRound. Each player has a number of operations which model the various contributions he/she can make to the game. In the example, we have the operation bid Request which asks a player to make a bid. The bid is registered by invoking the bid Accept method of the part-activity theBidding. class Player : public Participant { public: // ... void bid_Request( BiddingActivity& ba ); private: Bid players_bid; }; void Player::bid_Request( BiddingActivity& ba ) { // get bid from player and store in player_bid // Bidding activity accepts player's bid // and processes it ba.bid_Accept( this, player_bid ); }Player thePlayers[4]; In Figure 7, we illustrate the activities, partactivities, and participants of this simpli ed example. In theRound, the activate method will sequentially invoke the part-activities theDealing, theBidding and theTricks. theRound is itself invoked in the mainprogram. virtual void RoundActivity::activate() { // mark activity as begun, // activate theDealing, // activate theBidding, 7 theTricks activate activate activate activate bid-Request bid-Request bid-Request bid-Request bid_Accept theDealing theRound theBidding thePlayers[0] thePlayers[1] thePlayers[2] thePlayers[3] Figure 7: Example: Card Game // activate theTricks, and // mark activity as complete }void main() { // ... theRound.activate(); } 3.1 Initiating Activities An initiating activity will execute its activate method throughout its lifetime. This activity is set into progress by invoking this method { this method will determine when the activity must end and will then terminate itself. Initiating Activity Class. The activate method of this class is structured thus: class InitiatingActivity : public Activity { // ... virtual void activate() { beginActivity(); // perform actions endActivity(); } }; The general form of an accept method is: void method_Accept() { if ( inProgress() ) // perform actions else // handle error! } We assume the existence of a display object that allows user interaction with the objects in our example. display is initialized and will then be passive { in contrast to the activate method of theActivity, which will actively execute: void main() { // ... display.initialize(); theActivity.activate(); } aP1 aP2 aP4 activate theActivity F_Accept aP3 Figure 8: Initiating Activity Initiating Schematic Example. In Figure 8 we illustrate the initiating activity theActivity and the participants aP1 to aP4. theActivity executes activate, which at some point calls a method of aP4, which contributes to the activity by calling the F Accept method of theActivity. In SomeActivity we extend the description of activate. activate may start other part-activities such as pa1 by executing pa1.activate: class SomeActivity : public InitiatingActivity { // ... }; void SomeActivity::activate() { beginActivity(); pa1->activate(); pa2->activate(); endActivity(); }In Figure 9, we illustrate an initiating activity theActivity and two part-activities pa1 and pa2. When the activate method of theActivity is invoked, it will call the activate method of pa1 at some point. In PartActivity1 we describe F1 Request and activate. The activity will check that the execution of an operation F1 Request is legal, and will register the execution of F1 Request: 8 activate activate activate pa1 pa2 theActivity F_Accept F1_Accept F2_Accept Figure 9: Initiating Activity and Part-Activities class PartActivity1 : public InitiatingActivity { // ... }void PartActivity1::F1_Accept() { if ( inProgress() ) // perform actions else // handle error! }void PartActivity1::activate() { beginActivity(); // call to a participant aParticipant.F1_Request( this ); endActivity(); }activate may ask a participant to be active (by aParticipant.F1 Request) and to call one of the methods (either a speci c method or just anyone), for example F1 Accept, of the activity. activate F1_Request pa1 aParticipant F1_Accept Figure 10: Initiating Activity and Participant In Figure 10 we illustrate an initiating partactivity pa1 and a participant aParticipant. The activity pa1 executes its activate, which calls aParticipant's F1 Request method, which contributes by calling the F1 Accept method of pa1. Example: Initiating Card Game. In a RoundActivity, the activate method will sequentially activate the part-activities theDealing, theBidding, and theTricks: virtual void RoundActivity::activate() { beginActivity(); theDealing.activate(); theBidding.activate(); theTricks.activate(); endActivity(); }The BiddingActivity has an operation bid Accept available to the players for placing their bids. The lifecycle of BiddingActivity is repeatedly to nd and ask the next player to bid until the bidding is over according to the rules of the card game. class BiddingActivity : public InitiatingActivity { // ... virtual void activate(); void bid_Accept( Player& p, Bid& b ); }; void BiddingActivity:: bid_Accept( Player& p, Bid& b) { if ( inProgress() ) { // validate bid "b" made by player "p" // if this is the highest bid, // record it & the player who made it // set "winnerFound" to TRUE } else // handle error! }void BiddingActivity::activate() { Player& next_player; beginActivity(); do { // get next player and store in "next_player" // then call the "next_player" participant next_player.bid_Request( this ); } while ( ! winner_found ); endActivity(); }The passive display object is activated by the Player participant to prompt the user to enter a bid. class Player : public Participant { // ... void bid_Request( BiddingActivity& ba ); }; void Player::bid_Request( BiddingActivity& ba ) { Bid new_bid; 9 display << "Give me some bid"; display >> new_bid; // call to activity ba.bid_Accept( new_bid ); } theTricks activate activate activate activate bid-Request bid-Request bid-Request bid-Request bid_Accept theDealing theRound theBidding thePlayers[0] thePlayers[1] thePlayers[2] thePlayers[3] Figure 11: Example: Card Game RoundActivity In Figure 11, we illustrate a calling sequence in the RoundActivity example. theRound activity has called the part-activity theBidding, which in turn calls bid Request of thePlayers[2]. This participant contributes to the bidding activity by invoking the bid Accept method of theBidding. After each bid is made, theBidding may call the next player to contribute to the bidding process. display activate bid-Request theRound thePlayers[2] activate bid_Accept theBidding Figure 12: Example: Display and Users In Figure 12, we illustrate how the activate method of theRound is invoked from the main program. The bid Request method will get a new bid from the user via the display before invoking the bid Accept method of theBidding. 3.2 Reacting Activities A reacting activity will have its activate method executed whenever an action in relation to the activity has taken place. It is executed initially and then successively as a side-e ect of the execution of an accept-method. Finally it will determine the completion of the activity and terminate itself. Reacting Activity Class. The activate method of the ReactingActivity class is speci ed as: class ReactingActivity : public Activity { // ... }; void ReactingActivity::activate() { if ( parent != NULL) parent->activate(); } Methods of reacting activities will take the following form (notice the call to activate after a method has completed its actions): void method_Accept() { if ( inProgress() ) { // perform actions activate(); } else // handle error! } In subclasses of ReactingActivity, the activate method should be structured as follows: void activate() { if ( first_time ) { beginActivity(); first_time = FALSE; }if ( inProgress() ) { // perform actions // when finished endActivity(); // perform default action ReactingActivity::activate(); } else // handle error! } 10 The initial test for first time ensures execution of the beginActivity method only once. After the activity has completed its actions, endActivity is invoked. Following this, the activity invokes its parent's activate method, propagating the activation up the inheritance hierarchy. The activity is passive; activate is only executed when a participant has called one of its methods (e.g. F Accept) or there has been some activity in a partactivity. The activate method of theActivity is invoked as an initialization. theActivity will then be passive whereas display will be actively executing: void main() { // ... display.initialize(); theActivity.activate(); display.execute(); } activate aP1 aP2 aP3 aP4 theActivity F_Accept Figure 13: Reacting Activity Reacting Schematic Example. In Figure 13 we illustrate the reacting activity theActivity and the participants aP1 to aP4. The execution of a call a method of aP4, contributes by a call of the F Accept method of theActivity, which then executes activate as a side-e ect. In SomeActivity we extend the description of activate. activate assumes that beginActivity has already been executed to set hasBegun to True. When the activity is over, activate will end and set isComplete to True. activate may start other partactivities such as pa1 by executing pa1.beginActivity: class SomeActivity : public ReactingActivity { // ... }; void SomeActivity::activate() { if ( first_time ) { beginActivity(); first_time = FALSE; }if ( inProgress() ) { sequence = PART_ACTIVITY1; switch( sequence ) { case PART_ACTIVITY1 : if ( pa1.hasBegun() == FALSE ) pa1.activate(); if ( pa1.isComplete() == FALSE ) { sequence = PART_ACTIVITY2; break; } case PART_ACTIVITY2 : if ( pa2.hasBegun() == FALSE ) pa2.activate(); if ( pa2.isComplete() == FALSE ) { sequence = END_ACTIVITY; break; } case END_ACTIVITY : endActivity(); sequence = NO_ACTIVITIES; break; case NO_ACTIVITIES : break; }// default behaviour ReactingActivity::activate(); } else // handle error! } activate activate activate pa1 pa2 theActivity F_Accept F1_Accept F2_Accept Figure 14: Reacting Activity and Part-Activities In Figure 14 we illustrate a reacting activity theActivity and two part-activities pa1 and pa2. The execution of the activate method of the part-activity pa1 as a side-e ect includes the execution of the activate method of theActivity. In PartActivity1 we describe F1 Request and activate. The activity will check that the execution of an operation F1 Request is legal, and will register the execution of F1 Request: class PartActivity1 : public ReactingActivity { // ... }void PartActivity1::F1_Accept() { if ( inProgress() ) { 11 // perform actions activate(); } else // handle error! }void PartActivity1::activate() { if ( first_time ) { beginActivity(); first_time = FALSE; }if ( inProgress() ) { // perform actions // when finished endActivity(); // perform default action ReactingActivity::activate(); } else // handle error! } activate F1_Request pa1 aParticipant F1_Accept Figure 15: Reacting Activity and Participant In Figure 15 we illustrate a reacting part-activity pa1 and a participant aParticipant. The execution of aParticipant's F1 Request method contributes by calling the F1 Accept method of pa1 and as a side-e ect pa1 executes its activate method. Once again, we assume the existence of a display object { in this scenario, display receives input from the user and calls the request method of aParticipant. Example: Reacting Card Game. The object theRound is a round of a card game. Its activate method will be invoked each time any of its methods { or the part-activities theDealing, theBidding, theTricks { are invoked by a player. activate will check the state of theRound, especially the state of the part-activity in progress, and control the sequential execution of these part-activities. Finally, it will mark the end of its own execution. virtual void RoundActivity::activate() { if ( first_time ) { beginActivity(); first_time = FALSE; }if ( inProgress() ) { sequence = DEAL_ACTIVITY; switch( sequence ) { case DEAL_ACTIVITY : if ( theDealing.hasBegun() == FALSE ) theDealing.activate(); if ( theDealing.isComplete() == FALSE ) { sequence = BID_ACTIVITY; break; } case BID_ACTIVITY : if ( theBidding.hasBegun() == FALSE ) theBidding.activate(); if ( theBidding.isComplete() == FALSE ) { sequence = TRICK_ACTIVITY; break; } case TRICK_ACTIVITY : if ( theTricks.hasBegun() == FALSE ) theTricks.activate(); if ( theTricks.isComplete() == FALSE ) { sequence = END_ACTIVITY; break; } case END_ACTIVITY : endActivity(); sequence = NO_ACTIVITIES; break; case NO_ACTIVITIES : break; }// default behaviour ReactingActivity::activate(); } else // handle error! }The BiddingActivity has an operation bid Accept available to the players for placing their bids. The lifecycle of BiddingActivity is only to check if the bidding is over according to the rules of the card game, each time a set Bid operation has been invoked by a player. void BiddingActivity:: bid_Accept( Player& p, Bid& b) { if ( inProgress() ) { // validate bid "b" made by player "p" // if this is the highest bid, // record it & the player who made it // set "winnerFound" to TRUE activate(); } else // handle error! }void BiddingActivity::activate() { // ... }A display object exists { it actively solicits user interaction, repeatedly invoking the appropriate 12 operations of the player objects. For example: thePlayer[2].bid Request( TheBA, the bid );. void Player:: bid_Request( BiddingActivity& ba, Bid& b ) { // call to activity ba.bid_Accept( b ); } theTricks activate activate activate activate bid-Request bid-Request bid-Request bid-Request bid_Accept theDealing theRound theBidding thePlayers[0] thePlayers[1] thePlayers[2] thePlayers[3] Figure 16: Example: Card Game RoundActivity In Figure 16 we illustrate a calling sequence in the card game example. The call of bid Request of thePlayers[2] implies the call of the bid Accept method of theBidding, and as a side-e ect, the activate methods of theBidding and theRound are executed in turn. The bid Request of another player may be called to contribute to the bidding process. display activate bid-Request theRound thePlayers[2] activate bid_Accept theBidding Figure 17: Example: Display and Users In Figure 17, we illustrate how the display is invoked from the main program. As the result of some interaction with a user the display will invoke the bid Request and supply some new bid. 4 The Experimental Project The activity abstraction was invested in a project described in [May 94]. The project's objective was to explore issues related to the design and construction of object-oriented frameworks { the C++ language was used to build software artefacts through the course of the project. The problem domain that the study concentrated on was that of card games; namely, designing a framework for writing card game applications. Several pieces of software were produced: a Blackjack game (to gain experience in the problem area), a card game framework, and a Five Hundred game (to exercise the framework). More importantly, the project highlighted important issues of software development. Speci cally: Framework architecture: How abstract/concrete should a framework be? More abstract frameworks o er increased exibility at the cost of additional time required for specialisation. Conversely, more concrete frameworks can save time by making assumptions that could also restrict application exibility. Integration of Frameworks with Di erent Platforms: How should a framework be constructed so as to work seamlessly as possible on di erent platforms? The challenge is to design an architecture that allows rich interaction with the user without embedding platform-dependent user interface details. Activities: How can more complicated sequences of interaction/process be represented in such a way as to simplify their complexity? The present paper has dealt with an approach to abstracting interaction between entities. A framework for activities was created, which later became the basis for a card game framework { it was eventually used to create the Five Hundred game. The study furnished an opportunity to experience framework construction, allowing scrutiny of insights 13 and hurdles that were eventually encountered. Thetime limitation of the project did not allow su cientrefactoring of the framework { redundant featurescould be eliminated, while installing further func-tionality. This illustrated the need for additionaltime to iterate a framework through successive ver-sions.Limitations were encountered using C++. In its\standard" form, the language lacks concurrencyand sequencing mechanisms that could have beenuseful in implementing activities. Additionally, thelack of standard, portable class libraries impinged onthe framework construction process.Overall, the project demonstrated that there aresubstantive aspects of software development thatstill require attention. There remains much moreto understand about devising software structures {techniques to enhance our design expressivity can befurther improved, as well as the tools/languages thatrealize our models.5 SummaryThe underlying assumption in this paper is thatin existing object-oriented methodologies and lan-guages, classes and objects appear as isolated el-ements with an implicit and poor description ofthe interaction structure between them. Activitiespresent a di erent type of abstraction which may beused to model such interaction structures. As such,they are important for the modeling of organizationand cooperation of classes and objects. We have de-scribed abstract classes in C++ to support the useof activities in this language.Given the similarity of C++ and other main-stream object-oriented languages with respect to therestricted set of object-oriented programming lan-guage constructs used in our implementation of ac-tivities in C++, translation to other languages is astraightforward process.Results and Restrictions. The main results maybe summarized as follows:Activities support the modeling of the orga-nization and cooperation of objects in object-oriented programming.Activities support modeling that is more similarand intuitive to our human understanding { inour clustering of information and abstracting ofdetail (particularly of processes).If implemented successfully, activities o er anorthogonal solution to expressing and manipu-lating interaction.The present paper does not discuss the sequenc-ing of multiple activities, which concurrently overlapin execution. We also have not discussed possibleapproaches for the dynamic inclusion/exclusion ofparticipants in an activity { our examples show par-ticipants whose membership in an activity is static.These restrictions are primarily due to lack ofmainstream language support for such capabilities.Related Work. Contracts [Helm et al. 90] arespeci cations of behavioral dependencies amongstcooperating objects. Contracts are object{externalabstractions and include invariants to be maintainedby the cooperating objects. The focus is on inter{object dependencies to make this explicit by meansof supporting language mechanisms. The result isthat the actions { i.e., the reactions of an objectto changes { are removed from the object and de-scribed explicitly in the contracts: The objects areturned into reactive objects, whereas the reaction{patterns for an object in its various relations withother objects are described in the corresponding con-tracts. The intention of the contract mechanismis not modeling of real world phenomena and theirinter-dependencies. Instead the intention is to have amathematical, centralized description, that supportsprovable properties.Challenges. There exist numerous issues with ac-tivities that remain to be investigated and/or re-solved:Overlapping activities: Often, the activitieswe wish model will not follow neat, consecutiveparcels of execution. They may overlap andmerge into each other at di erent times { wewish to seek methods of expressing such scenar-ios in our designs.Contexts: In non-trivial systems, activitieswill generally refer to a central context that rep-resents common information from which theseactivities will draw. Part-activities will not gen-erally execute in isolation or ignorance of their14 super-activities; they will usually serve the pur-poses of their parent activity and/or draw infor-mation from the context which they share.Fundamentally, contexts pose a problem for en-capsulation of activities { the challenge is to de-vise techniques for modeling such relationshipsbetween activities; perhaps formalising somestandard form of protocol for inter-activity com-municationExistence of activities: It should be possi-ble to represent the circumstances in which anactivity can be said to exist. Some activitiesmay have no reasonable existence outside cer-tain settings { for example, given the Five Hun-dred game, there is a phase of activity calledbidding at the commencement of the game. Weexplicitly created a class to represent this activ-ity and instantiated such an object at the ap-propriate point in the game.However, a more accurate view of the activ-ity would be to say that the activity of bid-ding is \not de ned" after a given point in thegame. Any attempt to instantiate such an activ-ity would result in failure { this is a more faithfulmodel of the card game; there is no such con-cept as bidding at later stages of the game. Ourpresent implementation allows a bidding activ-ity to be created outside of its logical scope.Concurrency issues: If activities are to attaina powerfully expressive level of use, concurrencymechanisms that can facilitate the interactivecommunication required of activities need to bedevised.Activities should possess the capability to blockexecution and continue, contingent on the ac-tion of other activities; a permission protocolshould also be speci ed in order to impose a hi-erarchy of activation procedures { it should bepossible to de ne di erent sets of rules regulat-ing the control/invocation of activities by otheractivities.Acknowledgments. Daniel May would like tothank Deeran Peethamparam for proofreading por-tions of the paper and discussion of its issues. Specialthanks should also go to Penny Rush, for making itpossible for him to complete the paper.References[Helm et al. 90] R.Helm, I.M.Holland, D.Gangopadhyay:Contracts: Specifying Behavioral Compositions inObject{oriented Systems. Proceedings of the Euro-pean Conference on Object{Oriented Programming/ Object-Oriented Systems, Languages and Appli-cations Conference, 1990.[Kristensen 93a] B.B.Kristensen: Transverse Classes &Objects in Object-Oriented Analysis, Design, andImplementation. Journal of Object-Oriented Pro-gramming, 1993.[Kristensen 93b] B.B.Kristensen: Transverse Activities:Abstractions in Object-Oriented Programming.Proceedings of International Symposium on ObjectTechnologies for Advanced Software (ISOTAS'93),1993.[May 94] D.C.M.May: Frameworks: An Excursion intoMetalevel Design and Other Discourses. Depart-ment of Computer Science, Monash University,1994.[Stroustrup 91] B.Stroustrup: The C++ ProgrammingLanguage. 2/E, Addison-Wesley 1991.Notation Summary Thread-of-control linkRelation between activity and participantAssociation between objectsActivity compositionTransverse activity with directiveObject with methods andmethod implementations Activity object with methodsand method implementations